Method and System for Manual and Autonomous Control of an Infusion Pump

ABSTRACT

A method and system for both autonomous and manual control of an infusion pump for delivering medication to a patient is provided.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a division of U.S. application Ser. No. 13/490,602filed on Jun. 7, 2012, which is a division of U.S. application Ser. No.13/489,603 filed on Jun. 6, 2012, which is a division of U.S.application Ser. No. 13/468,669 filed on May 10, 2012, which is adivision of U.S. application Ser. No. 11/557,926 filed on Nov. 8, 2006,which claims the benefit of U.S. provisional application 60/734,398,filed Nov. 8, 2005. The disclosures of these prior applications areconsidered part of and are hereby incorporated in its entirety byreference in the disclosure of this application.

TECHNICAL FIELD

The present invention relates to autonomous and manual control of aninfusion pump.

BACKGROUND

An infusion pump is used to infuse fluids, medication or nutrients intoa patient's circulatory system. It is generally used intravenously,although subcutaneous, arterial and epidural infusions are occasionallyused.

Infusion pumps can administer fluids in ways that would be impracticallyexpensive or unreliable if performed manually. For example, infusionpumps can administer 1 mL per hour injections (too small for a drip),injections every minute, injections with repeated boluses requested bythe patient, up to the maximum number per hour allowed (e.g. inpatient-controlled analgesia), or fluids whose volumes vary by the timeof day.

As infusion pumps can also produce quite high but controlled pressures,the pumps can inject controlled amounts of fluids subcutaneously(beneath the skin), or epidurally (just within the surface of thecentral nervous system—a very popular local spinal anesthesia forchildbirth).

SUMMARY

A method and system is provided for both autonomous and manual controlof an infusion pump for delivering medication to a patient. The manualcontrol may provided by an onboard assistance device allowing the userto make entries and corrections.

A method for directly transferring operating parameters from oneinfusion pump device to a second infusion pump device is described thatincludes providing a first infusion pump device including parameters tobe transferred, establishing a communications link from the firstinfusion pump device to a second infusion pump device, and transferringthe parameters from the first infusion pump device to the secondinfusion pump device.

Variously, the communication link may be established using wired means,by contact between the first infusion pump device and the secondinfusion pump device, or by using wireless means. Variously, theparameters may include historical treatment information, may includeuser information, or may include operating parameters.

A method of entering food information into an infusion pump system isdescribed that includes providing a foodstuff identification, and usingdevice assisted data entry to enter the foodstuff identification into aninfusion pump system. The method may also include using the enteredfoodstuff identification to retrieve foodstuff composition information.

Variously, the foodstuff identification may include a barcode, or mayinclude an RFID tag. Variously, the foodstuff identification may beentered using a scanner in an infusion pump system, or may be enteredusing an RFID reader in an infusion pump system.

An infusion pump system is described that includes an infusion pumpbody, a control system, and an RFID reader, wherein the RFID reader isin communication with the control system. The RFID reader may becontained within the infusion pump body, or form part of the infusionpump body.

A method for temporarily disabling a disruptive alert of an infusionpump system is described that includes receiving a request to disabledisruptive alerts from an infusion pump system for a specified period oftime, disabling disruptive alerts from the infusion pump system for thespecified period of time, and re-enabling disruptive alerts after thespecified period of time has passed. Health alerts may remain activeduring the specified period of time.

Variously, the specified period of time may be determined by thedifference between the current time and a requested time, or thespecified time may be determined by a request for a specified timeperiod.

A method of determining a treatment amount for an infusion pump systemis described that includes obtaining treatment information includingfoodstuff composition information, food on board information, andinsulin on board information, and determining a recommended bolus amountbased on the treatment information.

Variously, the foodstuff composition information may include acarbohydrate ratio, may include quantity information, or may includecarbohydrate, fat, and protein information.

The method may also include using user metabolism information incalculating a bolus amount. Variously, user metabolism information mayinclude insulin sensitivity information, or glucose sensitivityinformation.

A method of determining a treatment amount for an infusion pump systemis described that includes obtaining foodstuff composition informationincluding carbohydrate, fat, and protein composition information of afoodstuff; and determining a recommended bolus amount based on thefoodstuff composition information.

Determining a recommended bolus amount may also be based on usermetabolism information, or may also be based on a user's food on boardand insulin on board information. The foodstuff composition informationmay be entered into the infusion pump system using device assisted dataentry.

A method of determining a recommended bolus amount is described thatincludes obtaining user metabolism information, obtaining foodstuffcomposition information including carbohydrate, fat, and proteincomposition information using device assisted data entry, anddetermining a recommended bolus amount using the following equation:

Recommended bolus amount=Food Now*Carb Ratio+(BG−BGtarget)*insulinsensitivity−IOB+FOB,

where: IOB=f(t)*bolus;

FOB=f(t)*grams Carb Ratio+f(t)*grams Protein Ratio+f(t)*grams Fat ratio;and

-   -   Food Now=the amount and type of foodstuffs ingested expressed in        terms of grams, carbohydrates, proteins or fat.

The details of one or more embodiments of the invention are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the invention will be apparent from thedescription, drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is an illustration of an exemplary infusion pump system.

FIG. 2 is an illustration of a cross sectional view of the exemplaryinfusion pump system of FIG. 1.

FIG. 3 is an illustration of transferring data between two infusion pumpsystems.

FIG. 4 is a flow chart illustrating a method of assisted modification ofinfusion pump parameters.

FIG. 5 is a flow chart illustrating a method of providing external inputto modify infusion pump parameters.

FIG. 6 is a flow chart illustrating a method of analyzing receivedcriteria to determine or enhance a bolus amount in an infusion pumpsystem.

FIG. 7 is a flow chart illustrating a method of postponing alertmessages in an infusion pump system.

FIG. 8 is a flow chart illustrating a method of postponing medicationdispersion in an infusion pump system.

FIG. 9 is a flow chart illustrating a method of transferring infusionpump parameters to one or more devices.

FIG. 10 is a flow chart illustrating a method for entering food datainto an infusion pump to receive a treatment recommendation.

FIG. 11 is a block diagram illustrating an exemplary architecture foroperating and controlling an infusion pump system.

FIG. 12 is a schematic diagram of an example of a generic infusion pumpcomputing system.

DETAILED DESCRIPTION

A method and system for autonomous and manual control of an infusionpump system is described. The system may receive input, analyze input,display some or all analysis data to an infusion pump user, and mayperform modifications to one or more infusion pump parameters. Theinfusion pump system may automatically prompt the user to perform asystem task or modification. For example, when a blood glucose (“BG”)reading is dangerously high in the pump user, the system may prompt theuser with information regarding decisions on dispensing medication ornutrients into the pump user's circulatory system, such as insulinmedication to lower the BG level in the user. The user can then performvarious tasks, including, but not limited to, ignoring the prompt,implementing the suggested protocol, or modifying the suggested protocolbefore implementing the modified protocol. In one embodiment, uponreceiving a user requested modification, the system may present anddisplay information to the user indicating that the infusion pumpparameters should remain unchanged.

The methods described in this application can be performed manuallybased on a request from a pump user, automatically based on previouslyentered user data (e.g., an alarm or criteria set by the user), or acombination of both. The manual control may be provided by an onboardassistance system to allow the pump user to make entries and correctionsin the system.

FIG. 1 is an illustration of an exemplary infusion pump system 100 thatmay be used to perform the methods described in this disclosure.

The infusion pump system 100 includes a pump body 102, an infusion siteinterface 104, and a reservoir 105. The pump body 102 includes an upperhousing 106 and a lower housing 108 which define a periphery in whichthe mechanisms of a pump unit reside. The upper and lower housings 106,108 may include openings or penetrations for attachment and guidance ofthe infusion site interface 104 to the pump body 102. Additionally,openings in the pump body may allow for the installation of thereservoir 105 contained within the pump body 102, and maintenance of thereservoir 105 that may be in communication with the infusion siteinterface 104 for dispensing medication. In general, the infusion siteinterface 104 may provide for continuous or intermittent subcutaneousfluid infusion. One or more buttons 110 may be used to enter userrequests into the pump system.

FIG. 2 is an illustration of a cross sectional view of the exemplaryinfusion pump system of FIG. 1.

As shown, a mechanism is contained in the pump body 102 that comprisesthe reservoir 105, a drive mechanism 202 and a control system (notshown). The reservoir 105 is comprised of a distal end 204 and aproximal end 206, and is cylindrical in geometry with the distal end 204sealed by a moveable plunger 208 of matching geometry as the reservoir105 and the proximal end 206 are contained by a pump body septum 210.The infusion pump system 100 generally dispenses fluid when the drivemechanism 202 is actuated, thereby applying pressure internal to thereservoir, such that a substance contained within the reservoir may bedriven through a device (not shown) that may pierce the pump body septum210. The actuation of the drive mechanism 202 may be governed by thecontrol mechanism. The geometry of the reservoir 105 has been shown ascylindrical for illustrative purposes only and as such, the reservoir105 is geometry independent.

In addition to the functionality of the pump system, the system may alsoinclude communication circuitry and functionality to upload, download orotherwise transfer data to and from the pump system. For example, theinfusion pump system 100 may transfer, upload, or download data to acomputer, a data repository, to itself, or to another infusion pump, toname a few examples. In particular, the infusion pump system 100 mayinclude circuitry designed for sending and receiving data, such ascommunication chipsets including, but not limited to, universal serialbus (USB), RS-232, Ethernet, Bluetooth, radio frequency, infrared,wireless Ethernet, or other such technologies. As shown in FIG. 2, thesystem 100 may include an infrared port 212, a USB port 214, and a radiofrequency identification (RFID) reader 216. In some implementations,rather than having an internal RFID reader, the infusion pump system mayinclude circuitry for connecting an external RFID reader. In someimplementations, some, all, or none of the above communication chipsets,connectors, or technologies may be included in the system, and as such,other ports and connector technologies are possible.

In some implementations, additional communication ports (not shown) maybe available for connecting peripheral data collection devices. The datacollection devices may be used to enter input into the infusion pumpsystem. The data collection devices may include, but are not limited to,a bar code scanner, a radio frequency (RF) reader, an optical scanner,an infrared scanner, or other wired or wireless data collection device.The data collection device may allow data to be uploaded or entered intothe pump system by selecting or scanning food and medicationinformation, for example. In some implementations, the pump user maydownload data from a website, or other means where wired or wirelesscommunication is available (e.g., a mobile telephone, or a personaldigital assistant (PDA)).

The pump user may collect data for the infusion pump system in variousways. Device assisted data entry may be utilized to obtain additionalinformation beyond that which may be easily entered using a manualapproach. For example, a pump user may user the USB port 214 to plug ina barcode scanner, and can scan foodstuffs to obtain additionalinformation, such as carbohydrate, fat, and protein amounts, mass,brand, food group, or other foodstuff identifying features. In otherimplementation, the infusion pump system may include an on-board barcodescanner. Using a barcode scanner, the user may scan the foodstuff itemand enter one or more identifying features in the user interface. Insome implementations, the pump user may use an onboard RFID reader 216to scan RFID tags located on foodstuffs, rather than a barcode reader.In other implementations, a RFID reader may be plugged in a USB port orother input/output port. In other implementation, other device assisteddata-entry approaches may be used. Furthermore, in other embodiments,wireless device assisted data entry implementations may be used (e.g., awireless RFID reader or wireless barcode scanner may be used tocommunicate foodstuff information to the infusion pump system).

In some implementation, the foodstuff information may include a productidentifier or code. The product identifier or code may be used to obtainadditional product information from an onboard data repository. Thus, aUPC code may be used to identify a foodstuff, which is then looked up ina data repository to obtain nutrition and other information regardingthe foodstuff.

Collecting data in the infusion pump system may be advantageous whencalculating treatment methods for pump users. For example, datacollection devices may also provide a method for entering foodidentification and composition information. The composition informationmay comprise a carbohydrate ratio, quantity information, carbohydratecontent, fat content, or protein content. In some implementations, thecollected data may be used to determine and recommend a particular bolusamount.

FIG. 3 is an exemplary illustration of transferring data between twoinfusion pump systems.

In general, a first pump 302 and a second pump 304 may establishpump-to-pump communications to transfer data between the pumps.Specifically, one or more communication ports on the pumps may initiatethe communication. For example, an infrared port on the first pump 302may initiate communication with an infrared port on the second pump 304upon coming into close proximity. In some implementations, thecommunication may be a wired communication where a pump user has“connected” the pumps together (e.g., as in a USB to USB cableconnection). Regardless of which pump initiated the connection, aportion of data may be bi-directionally transferred between both pumps,as facilitated by a pump user. In some implementations, no data may betransferred (e.g., when a pump user has not requested a transfer).

After the communication protocol is established, the transferring ofdata may commence. In particular, the processing devices on each pumpmay invoke their respective data repositories to begin transferring databetween the pumps. In general, operating parameters, historicaltreatment data, user information, configuration data, pump user data,pump manufacturer data, medication on board, and other systeminformation may be transferred from one pump to another pump.

FIG. 4 is a flow chart illustrating a method 400 of assistedmodification of infusion pump parameters.

The method 400 will be described in reference to an infusion pump systemthat processes user requests and infuses fluids, medication, nutrientsor other materials into the body of the pump user. The user requests mayinclude various modifications to system operating parameters, such asmodifications to bolus profile, basal rate, RTC, BG history, deliveryhistory, bolus history, and others. The list of operating parametersdescribed above is not an exhaustive list and as such, other parametersmay be modified manually or autonomously in the system.

The method 400 begins with the receipt 410 of an external input. Theinput may include updates for FOB information, IOB information,medication details, or simply include a request for modification of oneor more system parameters. The input can be manually entered into theinfusion pump via a control center, graphical user interface, bar codereader, radio frequency (RF) reader, optical reader, infrared reader,wireless transmission, email, text message, Internet, or other means.

After the input is received, and after any optional pre-processing, theinfusion pump may analyze 420 the received data to determine whether theinput is a request to modify, or other system task. For example, arequest for performing a calculation in the system may be carried outimmediately, since the effect of performing the calculation isinformational to the user (e.g., the calculation does not change atreatment parameter and may therefore be completed upon request).However, some requests include modifying medication levels or rates mayrequire further analysis to determine whether or not to carry therequest out, as received. When modifications are requested or proposed,further processing may be carried out using system data, input data, orstored data, and the user may be prompted to approve such modifications.

Upon completion of the analysis, further calculations may be performed430 to determine what effect, if any, the modification may have on thepump user. For example, a diabetic pump user may manually enter a fooditem that is about to be consumed. The pump user may wish topreemptively view FOB values and the corresponding bolus amount ofinsulin that will be infused if the user consumes the entered food.Here, the calculation can be performed and a suggested bolus amount canbe presented to the pump user.

Calculation feedback, instructions, or other information may bepresented 440 to the user audibly, visually, or via another sense, suchas a vibration (e.g., such that the user can feel an alarm is beinggenerated). Typically, the information is displayed to the user in auser interface, but multiple modes of presentation may be possible. Uponpresentation of the information, the user may input further information,make selections, or ignore the display.

In some implementations, the system may inquire about performingprocesses in the infusion pump. For example, the infusion pump may querythe pump user to impart permission to perform 450 a modification in thesystem. In this example, a request may have generated the query, oralternatively, the system may automatically generate the query torequest permission for performing a system function. In someimplementations, a query may display to inquire about a preprogrammedevent, such as a treatment change.

The pump user may receive queries in the graphical user interface thatpertain to system processes, parameters, events, or other items. Theuser may choose to respond to a query or request from the pump system.In the event that a query is generated requesting permission to performa system parameter modification, the user may choose to accept themodification. Upon receiving permission to perform the intendedmodification, the infusion pump system can perform 460 the requestedmodification.

Alternately, the pump user may disapprove of a particular modificationand thus may refuse permission to perform the modification.Additionally, the user may refuse permission and may enter modifiedinformation. The modified information can be applied and the query maybe regenerated such that the user can be presented the same query withthe updated information. In some embodiments, input from the user may beaccepted and implemented immediately and the system may not presentanother query to the user. The infusion pump system can obtain 470 theuser entered parameters or treatment correction and calculate 480 anappropriate modification. Upon determining the modification requested,the pump system may carry out 460 the requested modification(s). In someimplementations, the received input may not be a correction ormodification, but instead may be additional information for the systemto further process.

In some implementations, a user may input a request to modify a systemparameter, but inadvertently leave out a digit or instruction regardingthe parameter. In the event that data is missing or entered incorrectly,the system may not make the requested modification. In someimplementations, an indication of missing data may trigger an indicator,such as a display to the user, enabling the user to notice and correctthe error.

FIG. 5 is a flow chart illustrating a method 500 of providing externalinput to modify infusion pump parameters.

The method 500 will be described in reference to an infusion pump systemthat can receive input. Variously, pump users or medical staff canprovide information to the pump system in various ways, including manualentry, or data entry by other methods, such as a transmission, automateddata entry, or other method. In one embodiment, the user may provideupdates for one or more system operating parameters, such as a bolusprofile, basal rate, RTC, or BG history to name a few examples. Inanother embodiment, the user may provide food values or medicationvalues to assist the pump system with future processing of calculations.In yet another embodiment, the user may provide a pump configurationrequest, whereby the pump system can reconfigure itself according to theinput, or alternatively, the pump system can download or upload pumpcontents in preparation for a pump replacement. Other manually enteredinput may be possible.

The method 500 begins by receiving one or more inputs from the user. Ifthe user inputs 502 update parameters, the system may receive 504 theinput in a control module, for example. The control module may determinethe type of information entered. Accordingly, this may involve one ormore queries to determine the purpose of the entry. Thus, the system mayassess 506 whether or not a parameter update is being requested by theuser. If the entered input is indeed a parameter update, the system mayupdate 508 the parameter according to system rules. System rules mayinclude various error checking mechanisms to ensure a particularparameter update does not endanger the health of the pump user. Uponcompleting the parameter update, the system may await another input fromthe user. The pump system may receive several entries and may have todistinguish between several types of input.

In some implementations, the user may enter 510 a food or medicationvalue into the system, instead of a parameter update as described above.The control module may determine 512 the type of information entered bythe user. If the input is a food value or medication value, the systemmay perform processing steps to recalibrate parameter values such thatthe pump system functions to the user's advantage. For example, the usermay enter food values for food about to be consumed. Accordingly, thepump system can perform calculations 514 to determine accurate treatmentvalues for the user in the next several hours, for example.

In some implementations, the user may enter 516 pump configurationrequests, such that a pump can be reconfigured or configured uponreplacement. Here, the system may again use the control module todetermine 518 the type of information entered by the user. Theconfiguration request may simply include resetting certain systemparameters, while leaving others intact. In another example, the usermay request configuration of a newly installed pump system (e.g., uponreplacement of an old pump system). Upon determining that the user hasrequested a pump configuration, the system may perform 520 theconfiguration of the pump system.

The user may also enter 522 other types of input that the system may ormay not recognize upon entry. For example, a database having variousfood values and their typical masses may be downloaded to the pumpsystem. Here, the database can be used to compare typical “servings” offood items against what a user may consume. In this example, thedatabase may be uploaded wirelessly from the Internet and may requirefurther user interaction to appropriately store and use the database inthe pump system. As such, an onboard assistance device may assist 524the user in walking through configuration steps to ensure the databaseoperates properly. The onboard assistance device may also intervene toassist the user for other unknown data entries.

FIG. 6 is a flow chart illustrating a method 600 of analyzing receivedcriteria to determine or enhance a bolus amount in an infusion pumpsystem.

The method 600 will be described in reference to an infusion pump systemthat analyzes user input to determine system parameter values, such asbolus amounts and rates. The method 600 may provide manual control ofthe infusion pump system by means of a device or program which assiststhe pump user with determining proper bolus amounts.

A healthy human body regulates insulin levels in the bloodstream usingthe pancreas organ. Insulin production relates closely to the rise of BGlevels in the body (e.g., when glucose levels rise, insulin levelsrise). A diabetic patient is unable to maintain consistent insulinlevels and proper insulin response, and may require external means toassist in regulating their insulin levels. Insulin pump therapy mayinfuse insulin into fatty tissues just beneath the surface of the skinin a diabetic patient. This may create a delay in the absorption ofinsulin into the bloodstream.

Typically, insulin levels rise well after a rise in glucose level, thus,timing is a key issue in the delivery of insulin. This can make itdifficult to adjust insulin levels in the body to an appropriate level.This may be compounded by the fact that most diabetics test their BGlevels after they finish eating, sometimes significantly later than thestart of the meal. Accordingly, external systems such as infusion pumpsmay be designed to account for time anomalies and the like whendelivering medication to a pump user.

In addition, users may have different profiles as relate to digestionand metabolism. For example, a user may have different glucosesensitivity than other users, and be able to tolerate a higher or lowerlevel of glucose. These particular individuals' metabolism may correlateto different glucose levels in the blood as a result of the samespecific food intake. As another example, a user may have differentinsulin sensitivity in which the same amount of insulin will have adifferent effect on the Blood glucose level in the bloodstream. Inaddition, the metabolism time of glucose and insulin for one user may befaster or slower than for other users.

The method 600 begins when the infusion pump system receives 610 inputfrom a pump user. For example, food on board (FOB) and insulin on board(IOB) values can be received in the pump system. FOB is a measurement offood previously consumed by a user. In one embodiment, FOB is ameasurement of food that has been consumed by a user, but not yetconverted into glucose usable by the body for metabolism. IOB is ameasurement of the insulin previously dosed to a user. In oneembodiment, IOB is a measure of the insulin that has been dosed to auser but not yet available for the metabolic process (i.e., insulin thathas not yet been absorbed into the bloodstream). In another embodiment,IOB is a measure of the total insulin in a user's system, includinginsulin in the bloodstream or in the tissues. Thus, it may be a measureof all insulin that has not yet been metabolized.

In various embodiments, the system may use the FOB and IOB to calculatebolus amounts. Using more powerful microprocessors, pumps may bedesigned to determine and utilize information concerning the individualuser. In various embodiments, individual parameters such as sensitivityto insulin, carbohydrates or other endocrine information may allow thepump to improve recommended treatments. In some implementations, thepump system may utilize food input and BG level input to accuratelydetermine when a particular meal was started, when a peak glucose levelwill occur, and/or what an uncorrected BG level should be.

An onboard assistance system may include a processing method, forexample, which incorporates carbohydrate, protein, and fat values todetermine a value for food on board (“FOB”) for the user. The FOBcalculation might correspond to the equivalent amount of carbohydratefor each of the protein and fat intakes. As such, the pump user mayrequest a task, and be given further assistance by the onboardassistance system to carry out the task with accuracy.

The onboard assistance program may include a monitoring method thatincorporates previously entered data and treatment information todetermine a value for insulin on board (“IOB”) for the user. In general,an IOB feature in a pump calculates the decay of insulin in the bodyafter a bolus of insulin is given to a pump user. The infusion pumpsystem may recognize current dosage levels that a user is receiving andfurther, can measure the dosage to determine future infusion dosages orrates. The pump user can input several variables that the pump systemcan utilize to recommend one or more treatments. Advantageously, usingan infusion pump having manual and autonomous control properties mayallow an accurate estimate of a particular bolus rate or amount. Inaddition, the pump user may have flexibility in entering and modifyingthe bolus rate or amount at any time.

In one embodiment, a recommended bolus amount may be determined 620using the following equation:

Recommended bolus amount=Food Now*Carb Ratio+(BG−BGtarget)*insulinsensitivity−IOB+FOB

where: IOB=f(t)*bolus

FOB=f(t)*grams Carb Ratio+f(t)*grams Protein Ratio+f(t)*grams Fat ratio

-   -   Food Now=the amount and type of foodstuffs ingested expressed in        terms of grams, carbohydrates, proteins or fat.

The bolus amount determined by the above equation may be modified orenhanced 630 based on a BG correction factor. The BG correction factormay be calculated as the difference between the measured BG level andthe target BG level. This difference, if any, may assist the pump userin determining if a midstream bolus correction factor is required ordesired, as well as determine the potential magnitude of correction. Ingeneral, the measured BG level is a function of time against foodstuffsintake and calculated by the formula described above.

In some implementations, the BG correction factor may be determined bythe maximum BG level whereby the maximum BG level is an individuallydetermined number. The maximum BG level may be based on factorsincluding prior history, experience, and desired treatment levels, andmay be set by the user or a health care provider. The maximum BG levelmay be input and the bolus correction factor may then be calculatedbased on the maximum BG level. This may assist the pump user indetermining if a midstream bolus correction factor may be required ordesired, as well as determining the potential magnitude of correction.

In some implementations, the maximum allowable BG may be provided asinput to the pump. In this example, the pump may analyze the input andsuggest an appropriate bolus amount and corresponding timing. Thisinformation may also allow the pump to suggest 640 midstream correctiveactions, such as a modification to an immediate or delayed bolus,additional BG checks or other recommended changes such as temporarysuspension of therapy. If the infusion pump suggests a midstream boluscorrection, a magnitude of correction can be determined 650 in the pumpsystem. In one embodiment, the infusion pump may calculate a bolusamount based on information including the total intake of grams ofcarbohydrates, fat and protein, as well as the timing of the intake. Abolus amount may be recommended by calculating 620 system parameters.The outcome of the calculations may be made available 660 to the pumpuser in the user interface, for example.

In some implementations, a delayed bolus feature may be implemented toprovide further precision in controlling a pump user's BG levels. Forexample, anticipating what a BG level may be after consumption of anentered foodstuff may allow the pump system to properly dose the pumpuser at an opportune time. In some implementations, the delayed bolusmay be user selectable. For example, pump users may enter the time atwhich a particular foodstuff was consumed and set a time to receive adose of insulin.

The modified treatment amount determined by the pump system may includethe use of additional factors not normally used in infusion pump systemssuch as insulin pumps. The advantages of using additional informationmay include obtaining a treatment that is individually suited to theuser, obtaining a treatment that has a better time profile to bettermatch actual food consumption and medicament infusion, obtaining atreatment based on additional foodstuff information, or obtaining atreatment that is based in part on user metabolism. The additionalinformation may be available due to increased processing and memoryabilities, new ways of looking at ways to utilize information, and newmethodologies to obtain information. For example, asking a user to entera large amount of foodstuff information leads to low compliance.However, methods described herein enable easy entry of foodstuffinformation, resulting a better compliance and ability to utilizeinformation.

FIG. 7 is a flow chart illustrating a method 700 of postponingdisruptive alert messages in an infusion pump system.

The method 700 will be described in reference to an alert messagingsystem in an infusion pump. The alert messaging system may alert a pumpuser audibly, visually, or via another sense, such as a vibration (e.g.,such that the user can feel an alarm is being generated). Visualindicators can include light emitting diodes (LEDs), touch screens,liquid crystal display (LCD) screens, or other visual devices. Audioindicators may include buzzer chips, piezoelectric indicators, or othertechnology, and the like. Thus, the alert messaging system can generatea disruptive alert to inform the user of an event.

In general, the alert messaging system may accept input from pump users,such as time, date and alarm or alert criteria. For example, the pumpuser may manually configure an alert-free period to suspend the receiptof the alerts for a set period of time (e.g. 4 hours). Alternatively,the pump user may manually request a suspension of the disruptive alertsuntil a certain specified time is reached (e.g. suspend until 6 am). Assuch, the pump may not produce or present audible, visual, or otherdisruptive alerts in that specified time period. In addition, the pumpmay be programmed to defer the alerts to either the resumption time orthe end of time of the alert-free period.

The method 700 begins with the receipt 710 of a request for postponementof alert messages. For example, the pump user may enter a request for analert-free period, or the system may activate a previously set alarm.Alert-free periods and alarms may be manually set by the pump user atany time. For example, preemptive alerts may be set in the pump systemand may automatically engage at a set time.

When the alert postponement period begins, the infusion pump may disable720 one or more indicators for the suspended alert. In someimplementations, certain types of disruptive alerts may be suspended andreplaced by other alert types. In one embodiment, the alert messagingsystem may replace audible or visual indicators with a vibrationindicator, so that the pump will vibrate to provide an alert. As anotherexample, a pump user may wish to suppress audio indicators for a longperiod of time, such as, during a seminar or meeting. Thus, the user maytemporarily suspend audio alert indicators, but may still receive visualmessaging and indicators.

In other implementations, all disruptive alerts may be suspended until aset time. The period of time may be determined by a requested period oftime or may be determined by the period of time until the requestedresumption time.

The method 700 may make inquiries over time to determine 730 whether ornot the alert suppression time has expired. If the time has notcompleted, the suppression remains in progress and the system awaitsexpiration of the suppression time. If, however, the suppression timehas expired, the alert indicators may be enabled 740 and the system mayfunction accordingly. In addition to suspending alert messages, the pumpsystem may also receive instructions to suspend other processes.

In some implementations, a health alert or alarm system may remainactive even while the disruptive alert system has been disabled.Disruptive alerts generally relate to events, such as dispensing a bolusamount, a programmed change in infusion amounts, a reminder to checkblood glucose levels, etc. Health alerts generally relate tohealth-critical events, which may have a significant health impact onthe user if not addressed. Examples of events that may generate a healthalerts include the container of medicine in the infusion pump reaching alow level, the container of medicine in the infusion pump being empty, asensed blockage of flow from the infusion pump, or other events. Asthese events have a high priority, a health alert or alarm system mayremain functional even during a requested alert suspension period.

As various pump devices may be bodily worn, and are typically very closeto the user in many cases, the alert system used by the pump devices maybe very disruptive and irritating. These disruptive alerts generallyinform the user that a dosage has occurred, that a requested bolus wasdelivered, or other event. In many cases the user may already know thatthe event will be occurring. The advantages of disabling a disruptivealert system includes the advantages of turning off such alerts duringmeetings, during rest periods, or during periods requiring enhancedconcentration. This enables the user (and others) to perform at anoptimal level without distraction for a requested period. After therequested period, the pump system will automatically return to normaloperation. Thus, no additional input or request is needed to return tonormal operation. In addition, however, other types of alarms may bevery important to the user, such as health alerts, that inform the userof a critical failure, problem, or other issue. These alarms may remainenabled even during the requested period for disabling disruptivealerts. This provides additional assurance and peace of mind to the userthat critical alarms will not be missed.

FIG. 8 is a flow chart illustrating a method 800 of postponingmedication dispersion in an infusion pump system.

The infusion pump may be equipped with a feature whereby the delivery ofmedication may be suspended temporarily at a specified time. The method800 begins when the duration and time of suspension are entered 810 bythe pump user, such as a patient or nurse, and the system can alert theuser of the suspended status at a predetermined interval or period oftime. The input can be manually entered into the infusion pump via acontrol center, graphical user interface, bar code reader, radiofrequency (RF) reader, optical reader, infrared reader, wirelesstransmission via email or Internet, or other means suitable to enterdata into a processing device.

Upon receiving a request to suspend medication, the system may disable820 the medication delivery system. In some implementations, ifsuspended, the delivery of medication may be automatically or manuallyrestarted after a predetermined period of time. In otherimplementations, the system may periodically assess 830 whether or notthe entered suspension time has expired. If the suspension time has notexpired, the system may continue to suspend medication and additionalassessments may be performed in the future.

The medication delivery system may be enabled 840 for various reasons.In some implementations, expiration of the suspension time may invokethe pump system to enable the medication delivery system. In otherimplementations, a pump user may interrupt the medication deliverysuspension to receive medications. For example, the pump user may befeeling symptoms that may require medication.

FIG. 9 is a flow chart illustrating a method 900 of transferringinfusion pump parameters to one or more devices.

At various times, the pump system may need to be replaced to ensureproper treatment of the user. For example, over time, the components ina pump may wear out and require replacing. In one embodiment, the pumpsystem may include a mechanism portion, and a control portion that maybe communicably coupled and uncoupled when either portion is replaced.In some implementations, the mechanism portion may be detachable anddisposable, while the control portion remains intact. For example, anold pump mechanism may be replaced by a new pump mechanism. In otherimplementations, the entire pump system may be a single unit, withnon-detachable mechanism and control portions. In some embodiments, themechanism and control portions may be integrated.

The method of autonomous control may be initiated for a new orpreviously unused pump by the transfer of parameters from a current pumpsystem to initiate proper operation. The program and information may bethe entire set of parameters including, but not limited to, bolusprofile, basal rate, real time clock (“RTC”), blood glucose history,delivery history, and bolus history. The transfer of parameters may beaccomplished by transfer from an active or previously programmed unit ora separate programming device to a new, unused or unprogrammed unit.Parameters can be transferred to the new pump by either wired orwireless communications.

The method 900 begins when the infusion pump system receives 910 arequest to transfer parameters. In particular, a pump user may manuallyenter a request to upload or download pump operating parameters orfeedback of suggested manual parameters to a database, another pump, theInternet, or various computer programs or computer files, to name a fewexamples. In some implementations, the data to be transferred can bestored internally or externally before a transfer is performed.

In some implementations, the method of autonomous control may beinitiated for a new or previously unused pump by the automatic transferof parameters by which the pump may initiate proper operation. Suchoperating parameters may include, but are not limited to, bolus profile,basal rate, RTC, BG history, delivery history, and bolus history. In oneembodiment, the transfer of parameters may be accomplished by transferfrom an active or previously programmed unit to a new, unused orunprogrammed unit. In another embodiment, the transfer of parameters maybe downloaded to a database and uploaded to the unprogrammed unit atanother time. Alternatively, a new or unprogrammed pump may have theprogram and information loaded from a separate programming device. Theseparate programming device may be connected to an external computer ordevice with an interface that may run on graphical user interface (GUI)standards associated with that computer.

In general, when a transfer is requested, the pump user may determine920 a sending device from which the parameters and feedback will betransferred. In one embodiment, the sending device may be the currentpump device. In other embodiments, the sending device may be a database,a digital computing device such as a laptop, desktop, workstation,personal digital assistant, server, or another device communicablycoupled to the system.

After determining the sending device, the user may determine 930 themethod of transfer. This transfer may be initiated by means of direct,pump-to-pump physical contact, an infrared port, wireless connection, orby method and means of a wired connection, such as through a USB port, aserial port, or other technologies. The information transferred mayprovide a seamless transition between the “old” pump (sending device)and the “new” pump. Using a wired connection to transfer the parametersmay facilitate communication by way of acoustic, electromagnetic,optical or other form of signaling. Ideally, the connection may be madeand the transfer of information may be completed before the use of thepump. The transfer of parameters can also be accomplished using wirelesscommunication between the pumps. In general, the wireless transfer ofparameters or files can be sent from the sending device to a receivingdevice (e.g., a new infusion pump) through a wireless connection, suchas Bluetooth, Ethernet, or wireless Ethernet, to name a few examples.

In the event that the transfer determined between two infusion pumps,the receiving device may be configured 940 appropriately to receivedata. For example, memory on the device may be erased or configured toreceive an upload of data, or other parameters, such as alert systemsand displays may be tested for proper functionality. In addition, thecommunication link may be tested 950 to ensure proper bandwidth orsufficiency of streaming. The communication link may fail prior to orconcurrently with the initiation of the transfer. In this example, oneor more configuration programs may be performed again, in an attempt torepair the link.

Once the configuration is complete and the data is ready for transfer,the parameters may be transferred 960 to the new pump. Upon completionof the transfer, the pump user may manually enable other systems on thenew pump, install medication supplies, or enter further data. In someimplementations, the pump system may indicate, visually or audibly, thatfurther action is required from the pump user. In some implementations,the new pump system may perform a system check routine to ensure thepump will properly operate.

Direct communication from pump to pump enables a user to transferoperating history, user information, configuration parameters, and otherinformation directly form one unit to another. The advantages of such anapproach may include the ability to make such a transfer withoutrequiring any additional equipment or setup. An approach that requires,for example, uploading and downloading from an internet site requires aninternet connection, access to the specific site, and additionalequipment. The user may not have all of these elements when a pump unitbegins to fail. Thus, pump to pump direct transfer enables theinformation to be captured in a new pump unit rather than lost in caseswhere the website is down for maintenance, the internet connection isslow or non-existent, or the user is on vacation or other location whereadditional equipment may not be present. Direct communication from pumpnit to pump unit also enables the use of disposable pump units, whilestill retaining information and history. For example, direct pumpinformation transfer may transfer identification, configuration, anduser information, resulting in an easy and direct initialization of asecond pump unit. In addition, operating history, historical dosage andconsumption information may be transferred directly to a new pump unit.Thus, the user may completely replace the equipment used, but have thefull information available in the new unit. Such an approach is notuseful, and in fact, cannot be done where a pump unit is “dumb”, andcontains no processing or memory storage. Rather than using a separatecontrol unit for all functions, and a pump unit for just dosing, a“smart” pump unit enables the use and transfer of information from thepump unit itself. Incorporating processing and memory capacity into thepump unit enables the use and transfer of additional information fromone pump unit to another.

FIG. 10 is a flow chart illustrating a method 1000 for entering fooddata into an infusion pump to receive a treatment recommendation.

The method 1000 begins when personal user information is obtained 1010from the user, or alternatively, accessed from the pump system. The pumpuser may manually enter personal information such as weight, medicationingested, exercise performed, or other health characteristics, and thesystem will store that data until needed in system analysis, forexample. In some implementations, the personal user information can beused for analysis in determining recommended treatments or othersuggestions for the pump user.

Next, the user may enter 1020 food information pertaining to foodingested for the day, or food about to be ingested. For example, theuser may wish to know how much of a specific food item can be ingestedwithout requiring medication. In another example, the user may simplywish to view statistics regarding prior consumption of the entered food.

In one example, the entered data may be analyzed, or compared 1030 withpersonal user information to determine proper bolus amounts and rates.For example, from the analyzed data, the system may internally determinethe parameters for FOB and recommended bolus amount such as the exampledescribed in FIG. 3 above. In some implementations, the comparison 1030may be performed to increase or decrease a medication dosage. Forexample, if the pump user has ingested a particularly high quantity ofsugar filled food in one day, an analysis may be performed to determinewhether or not to increase the insulin dosage.

Thus, user entered data may be used to determine 1040 any number ofrecommended treatments to benefit the health of the pump user.Recommended treatments may include medication dosages, consultantnotices (e.g., consult a physician), technical support (e.g., to repairthe pump for some reason), or simply recommendations on food consumption(e.g., dietary recommendations) and the like. Other treatmentrecommendations are possible in the system.

Some, all, or none of the determined treatments may be presented 1050 tothe pump user in the user interface of the pump device. The pump usermay accept, modify, or decline a proposed treatment. As such, treatmentrecommendations may typically await user feedback before carrying outthe actual treatment. In some implementations, the recommended treatmentmay require a doctor's visit. In other implementations, the pump systemmay carry out the recommended treatment after the user accepts thetreatment.

The user may also enter other types of input into the system. In oneembodiment, device-assisted data entry may be used to enter foodstuffinformation. Typically, a user may be willing to enter carbohydrateinformation related to the food consumed. However, requesting additionalinformation generally results in poor compliance. Using device-assisteddata entry provides a method of obtaining additional foodstuffinformation that may be useful in determining recommended treatmentamounts of a medicine or other material. Examples of device-assisteddata entry include the use of barcode information, RFID tags, or foodcodes. The information may enter the pump system via variouscommunication interfaces, such as those shown in the example embodimentof FIGS. 1-3.

In some embodiments, the data entered may include foodstuff informationdirectly, such as amount of calories, carbohydrates, fats, and proteins.In most embodiments, however, the data entered may be used as a key orcode by the system to obtain additional foodstuff information. Forexample, a database having various food values (including carbohydrate,fat, and protein content), and their typical amounts may be downloadedto the pump system. The database can be used to compare typical“servings” of food items against what a user may consume. Thedevice-assisted data entry may enter a code value, which is then lookedup in the database by the system to obtain various food values. Thedatabase may be provided as part of the pump system, may be uploadedwirelessly from the Internet, and/or may require further userinteraction to appropriately store and use the database in the pumpsystem. As such, an onboard assistance device may assist 524 the user inwalking through configuration steps to ensure the database operatesproperly. The onboard assistance device may also intervene to assist theuser for other unknown data entries.

The advantages of such an approach include the ability to utilizeadditional foodstuff information for the treatment of the user.Importantly, the additional foodstuff information may be obtainedwithout requiring numerous additional steps or tasks by the user, and insame cases may require less input from a user. Thus, an approach thatincludes additional foodstuff information, enabling better treatment,may be easier for the user. As device assisted data entry may be easier,this approach may also increase user compliance with entering food andconsumption information.

In some implementations, the methods 400-1000 may be performed byprocessing devices, such as those shown in FIG. 12 of this description.The processing devices may be located in a control unit, in the pumpbody, or in some combination thereof. In particular, when processingequipment is used by one of the above methods, the system may select oneor more devices, from the system in FIG. 12 or another system, toperform the operations in the methods. In addition, the input receivedin the system, or as part of the above operations may be received in auser interface, such as through a touch screen, keyboard, or othermanual entry device, a data collection device, such as can be connectedto interfaces 212, 214, or 216.

Several systems may be used to carry out the operations in the methodsdescribed above. As such, FIG. 11 is simply one exemplary system forperforming the operations in FIGS. 4-10. Accordingly, the abovedescription of example embodiments does not define or constrain thisdisclosure to a particular system. Other changes, substitutions, andalterations are also possible without departing from the spirit andscope of this disclosure.

FIG. 11 is a block diagram illustrating an exemplary architecture 1100for operating and controlling an infusion pump system. For example, thearchitecture 1100 may receive user instructions in one or morecommunication interfaces, such as the infrared port 212, USB port 214,RFID reader 216, or another attached interface, and may then implementthe user instructions accordingly. In some implementations, thearchitecture may respond to user instructions or requests with inquiriesabout the user entered instructions. For example, if a foodstuff isreceived via the RFID reader 216, the architecture 1100 may respond torequest a particular mass for the entered foodstuff.

The architecture 1100 includes a control unit 1102 and a pump unit 1104that may be communicably coupled through interface 1106. The interface1106 facilitates wireless, wired, contact, near proximity, orcontactless communication between the control unit 1102 and the pumpunit 1104. While illustrated as a single or continuous interface, theinterface 1106 may be logically divided into individual interfaces oneither unit 1102 or 1104 without departing from the scope of thisdisclosure, so long as at least a portion of the interface 1106 mayfacilitate communications between the control unit 1102 and the pumpunit 1104.

The control unit 1102 may include various modules to perform functionsin the pump system. The modules may include a user interface module1108, a user assistance module 1110, a configuration module 1112, acontrol communication module 1114, and a processing module 1115. Themodules may interact with the pump user, the pump unit 1104, and othersystem components, as necessary to carry out system tasks. For example,the modules may control the dispensing of medication by controlling thereservoir 105. The modules may be stored in a nonvolatile storagelocation, such as data repository 1116 or another repository in thesystem, and may be transferred to memory 1116 for active use by thearchitecture 1100.

The user interface module 1108 may provide the user with a mechanism toinput data into the pump system. Here, the user interface module 1108may also display system information to the pump user, such as BG historyor recommended bolus information, for example.

The user assistance module 1110 may provide guidance and recommendationsto the user when a system function is scheduled, or when the user hasrequested a system modification. In some implementations, the userassistance module 1110 may provide suggestions and calculation values toassist the user in determining a course of action for the pump system.

The configuration module 1112 may configure the pump system upon userrequest. For example, pump components, such as the drive mechanism 202can be configured to the pump system parameters upon receiving a requestfrom the pump user. In addition, the configuration module 1112 mayconfigure a new pump upon installation. In general, the configurationmodule 1112 may be user controlled, and thus, may not have prior systemsettings. For example, pump users may input personal information to“calibrate” the configuration module 1112 to appropriate settings.

The control communication module 1114 may receive user information viathe user interface module 1108, a barcode reader, an RF reader, a PDA, acell phone, or other such technology, and transfer the data to the pumpunit 1104. For example, the control communication module 1114 maytransfer user entered data, calculation data, modification data,operating instructions, and the like to the pump unit 1104. The pumpunit 1104 may then carry out any instructions, or user modificationsthat the control unit 1102 deemed necessary.

The processing module 1115 may include one or more processors to executeinstructions and manipulate data for performing the operations of thecontrol unit 1104. The processing module 1115 may include a centralprocessing unit (CPU), an application specific integrated circuit(ASIC), a field-programmable gate array (FPGA), or other suitablehardware or software control system, for example.

The control unit 1102 may include local electronic storage capacity,such as data repository 1116. The data repository 1116 may include anymemory or database module and may take the form of volatile ornon-volatile memory including, without limitation, magnetic media,optical media, random access memory (RAM), read-only memory (ROM),removable media, or any other suitable local or remote memory component.The illustrated data repository 1116 may store system data, such asalert data, food data, medication data, reporting files, systemparameters, user entered data, and others.

The pump unit 1104 may include a pump communication module 1118, pumpcontrols 1120, and a pump mechanism 1122. In general, the pumpcommunication module 1118 may receive instructions from the controlcommunication module 1114. Specifically, user instructions or requestsmay be entered into the user interface module 1108 of the control unit1102, whereby, the control communication module 1114 may transfer theinstructions or requests into the pump communication module 1118. Themodule 1118 may then provide the information to the pump controls 1120which may translate the instructions for the pump mechanism 1122.

The pump controls 1120 may include one or more processors to executeinstructions and manipulate data for performing the operations of thepump unit 1104. The pump controls 1120 may include, for example, CPUs,ASICs, FPGAs, or other suitable hardware or software control system. Inthe illustrated implementation, the pump controls 1120 translateinstructions for the pump mechanism 1122. The pump mechanism 1122 maydeliver medication dosages to the pump user. For example, the pumpmechanism 1122 can deliver a medication such as insulin in a basal dose,or a bolus dose to correct BG levels in the pump user's body.

In some implementations, the control unit 1102 may be included as aportion of the pump unit 1104. In other implementations, the controlunit 1102 may be a separate, detachable entity from the pump unit 1104.Regardless of whether or not the control unit 1102 and the pump unit1104 are separate entities, in operation, system processing may occur inthe control unit 1102, in the pump unit 1104, or may occur in acombination of both.

FIG. 12 is a schematic diagram of an example of a generic infusion pumpcomputing system 1200. The system 1200 can be used for the operationsdescribed in association with the methods in this disclosure accordingto one implementation. For example, the system 1200 may be included inany or all of the computing system 800, the pumps 900, 1000 or 1100.

The system 1200 includes a processor 1210, a memory 1220, a storagedevice 1230, and an input/output device 1240. Each of the components1210, 1220, 1230, and 1240 are interconnected using a system bus 1250.The processor 1210 is capable of processing instructions for executionwithin the system 1200. In one implementation, the processor 1210 is asingle-threaded processor. In another implementation, the processor 1210is a multi-threaded processor. The processor 1210 is capable ofprocessing instructions stored in the memory 1220 or on the storagedevice 1230 to display graphical information for a user interface on theinput/output device 1240. The processors shown in FIG. 12 may beincluded in some, all, or none of the modules shown in FIG. 11. Theprocessors and modules may be located within a pump body (such as theexample pump body shown in FIGS. 1-3), or may be located within acontrol unit. In some embodiments, the control unit may be detachablefrom the pump body. In some embodiments, some of the modules orprocessors may be located in a control unit, while others are locatedwithin a pump body.

The memory 1220 stores information within the system 1200. In oneimplementation, the memory 1220 is a computer-readable medium. In oneimplementation, the memory 1220 is a volatile memory unit. In anotherimplementation, the memory 1220 is a non-volatile memory unit.

The storage device 1230 is capable of providing mass storage for thesystem 1200. In one implementation, the storage device 1230 is acomputer-readable medium. In various different implementations, thestorage device 1230 may be a floppy disk device, a hard disk device, anoptical disk device, or a tape device.

The input/output device 1240 provides input/output operations for thesystem 1200. In one implementation, the input/output device 1240includes a keyboard and/or pointing device. In another implementation,the input/output device 1240 includes a display unit for displayinggraphical user interfaces.

The features described can be implemented in digital electroniccircuitry, or in computer hardware, firmware, software, or incombinations of them. The apparatus can be implemented in a computerprogram product tangibly embodied in an information carrier, e.g., in amachine-readable storage device or in a propagated signal, for executionby a programmable processor; and method steps can be performed by aprogrammable processor executing a program of instructions to performfunctions of the described implementations by operating on input dataand generating output. The described features can be implementedadvantageously in one or more computer programs that are executable on aprogrammable system including at least one programmable processorcoupled to receive data and instructions from, and to transmit data andinstructions to, a data storage system, at least one input device, andat least one output device. A computer program is a set of instructionsthat can be used, directly or indirectly, in a computer to perform acertain activity or bring about a certain result. A computer program canbe written in any form of programming language, including compiled orinterpreted languages, and it can be deployed in any form, including asa stand-alone program or as a module, component, subroutine, or otherunit suitable for use in a computing environment.

Suitable processors for the execution of a program of instructionsinclude, by way of example, both general and special purposemicroprocessors, and the sole processor or one of multiple processors ofany kind of computer. Generally, a processor will receive instructionsand data from a read-only memory or a random access memory or both. Theessential elements of a computer are a processor for executinginstructions and one or more memories for storing instructions and data.Generally, a computing system will also include, or be operativelycoupled to communicate with, one or more mass storage devices forstoring data files; such devices include magnetic disks, such asinternal hard disks and removable disks; magneto-optical disks; andoptical disks. Storage devices suitable for tangibly embodying computerprogram instructions and data include all forms of non-volatile memory,including by way of example semiconductor memory devices, such as EPROM,EEPROM, and flash memory devices; magnetic disks such as internal harddisks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROMdisks. The processor and the memory can be supplemented by, orincorporated in, ASICs (application-specific integrated circuits).

To provide for interaction with a user, the features can be implementedon a computing device or infusion pump device having a display device anLCD (liquid crystal display) monitor for displaying information to theuser and a keyboard, keypad, or pointing device by which the user canprovide input to the computer.

In addition, the logic flows depicted in the figures do not require theparticular order shown, or sequential order, to achieve desirableresults. In addition, other steps may be provided, or steps may beeliminated, from the described flows, and other components may be addedto, or removed from, the described systems. Accordingly, otherimplementations are within the scope of the following claims.

While this specification contains many specifics, these should not beconstrued as limitations on the scope of the invention or of what may beclaimed, but rather as descriptions of features specific to particularembodiments of the invention. Certain features that are described inthis specification in the context of separate embodiments can also beimplemented in combination in a single embodiment. Conversely, variousfeatures that are described in the context of a single embodiment canalso be implemented in multiple embodiments separately or in anysuitable subcombination. Moreover, although features may be describedabove as acting in certain combinations, one or more features from aclaimed combination can in some cases be excised from the combination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the embodiments described above should not be understoodas requiring such separation in all embodiments, and it should beunderstood that the described program components and systems cangenerally be integrated together in a single software product orpackaged into multiple software products.

Although the present invention has been described with reference tospecific embodiments, these embodiments are illustrative only and notlimiting. Many other applications and embodiments of the presentinvention will be apparent in light of this disclosure and the followingclaims.

1. A method of determining a treatment amount for an infusion pumpsystem, comprising: obtaining treatment information including foodstuffcomposition information, food on board information, and insulin on boardinformation; and determining a recommended bolus amount based on thetreatment information.
 2. The method of claim 1, wherein the step ofobtaining treatment information comprises receiving data input from auser of the infusion pump system indicative of at least one of foodstuffcomposition information, food on board information, and insulin on boardinformation.
 3. The method of claim 1, wherein the foodstuff compositioninformation is obtained in response to receiving device-assisted dataentry of a foodstuff identification into the infusion pump system. 4.The method of claim 3, wherein the infusion pump system comprises afoodstuff data input device configured to provide said device-assisteddata entry of said foodstuff identification.
 5. The method of claim 4,wherein the infusion pump system comprises: a pump body; a medicinereservoir insertable into an interior space of the pump body through anopening in the pump body; a drive system positioned in the pump body;and a control system configured to communicate with the foodstuff datainput device.
 6. The method of claim 3, wherein the infusion pump systemis configured to use the entered foodstuff identification to retrievefoodstuff composition information.
 7. The method of claim 6, whereinsaid foodstuff composition information is retrieved from an onboard datarepository of said infusion pump system.
 8. The method of claim 6,wherein the foodstuff composition information retrieved by the infusionpump system includes carbohydrate, fat, and protein compositioninformation of a foodstuff.
 9. The method of claim 1, wherein the stepof determining the recommended bolus amount is based the followingequation:Recommended bolus amount=Food Now*Carb Ratio+(BG−BGtarget)*insulinsensitivity−IOB+FOB, where: IOB=f(t)*bolus;FOB=f(t)*grams Carb Ratio+f(t)*grams Protein Ratio+f(t)*grams Fat ratio;and Food Now=the amount and type of foodstuffs ingested expressed interms of grams, carbohydrates, proteins or fat.
 10. The method of claim1, wherein the foodstuff composition information comprises acarbohydrate ratio.
 11. The method of claim 1, wherein the foodstuffcomposition information further comprises quantity information.
 12. Themethod of claim 1, wherein the foodstuff composition informationcomprises carbohydrate, fat, and protein information.
 13. The method ofclaim 1, further comprising using user metabolism information incalculating a bolus amount.
 14. The method of claim 13, wherein the usermetabolism information comprises insulin sensitivity information. 15.The method of claim 13, wherein the user metabolism informationcomprises glucose sensitivity information.
 16. A method of determining atreatment amount for an infusion pump system, comprising: obtainingfoodstuff composition information including carbohydrate, fat, andprotein composition information of a foodstuff; and determining arecommended bolus amount based on the foodstuff composition information.17. The method of claim 16, wherein determining a recommended bolusamount is also based on user metabolism information.
 18. The method ofclaim 16, wherein determining a recommended bolus amount is also basedon a user's food on board and insulin on board information.
 19. Themethod of claim 16, wherein the foodstuff composition information isobtained in response to receiving device-assisted data entry of afoodstuff identification into the infusion pump system.
 20. The methodof claim 19, wherein the infusion pump system comprises a foodstuff datainput device configured to provide said device-assisted data entry ofsaid foodstuff identification.
 21. The method of claim 20, wherein theinfusion pump system comprises: a pump body; a medicine reservoirinsertable into an interior space of the pump body through an opening inthe pump body; a drive system positioned in the pump body; and a controlsystem configured to communicate with the foodstuff data input device.22. The method of claim 19, wherein the infusion pump system isconfigured to use the entered foodstuff identification to retrievefoodstuff composition information.
 23. A method of determining arecommended bolus amount, comprising: obtaining user metabolisminformation; obtaining foodstuff composition information includingcarbohydrate, fat, and protein composition information using deviceassisted data entry; and determining a recommended bolus amount usingthe following equation:Recommended bolus amount=Food Now*Carb Ratio+(BG−BGtarget)*insulinsensitivity−IOB+FOB, where: IOB=f(t)*bolus;FOB=f(t)*grams Carb Ratio+f(t)*grams Protein Ratio+f(t)*grams Fat ratio;and Food Now=the amount and type of foodstuffs ingested expressed interms of grams, carbohydrates, proteins or fat.
 24. The method of claim23, wherein the foodstuff composition information is obtained inresponse to receiving device-assisted data entry of a foodstuffidentification into the infusion pump system.
 25. The method of claim24, wherein the infusion pump system comprises a foodstuff data inputdevice configured to provide said device-assisted data entry of saidfoodstuff identification.
 26. The method of claim 25, wherein theinfusion pump system comprises: a pump body; a medicine reservoirinsertable into an interior space of the pump body through an opening inthe pump body; a drive system positioned in the pump body; and a controlsystem configured to communicate with the foodstuff data input device.27. The method of claim 24, wherein the infusion pump system isconfigured to use the entered foodstuff identification to retrievefoodstuff composition information.